home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 22 / Cream of the Crop 22.iso / program / snip9611.zip / ENVIRON.TXT < prev    next >
Text File  |  1996-11-24  |  7KB  |  120 lines
  1. +++Date last modified: 29-Oct-1996
  2.  
  3. Q. Is it possible to set an environment variable from within a program? I've
  4.    tried setnev() and it doesn't work.
  5.  
  6.  
  7. A. Generally, the answer is no. First of all, you must understand how
  8.    environment variables work. The command shell (COMMAND.COM, 4DOS, or any
  9.    of the Unix shells) is what maintains the environment variables. They are
  10.    stored, usually concatenated, in a block of memory owned by the command
  11.    shell. When your program runs, it inherits a copy of the environment
  12.    block. This is a crucial concept! The command shell only copies its
  13.    "master environment" and passes the copy to the program. When the program
  14.    terminates, its copy, which was in memory it owned, is discarded along
  15.    with any changes which were made to it. This is why putenv() seems not to
  16.    work, since it only modifies the copy and the changes are lost upon
  17.    program termination. Ultimately, the question you must answer is which
  18.    copy of the environment you wish to modify? If you only wish to modify
  19.    your local environment, use putenv(). If you want to modify something
  20.    else, you have more questions to answer. Remember that several copies of
  21.    the command shell may be running at a time, so which one's environment
  22.    block do you want to modify? If you choose to modify your parent process'
  23.    environment block, that too will be lost when your parent process
  24.    terminates. If you want to modify the original master, then your changes
  25.    may still be lost when you terminate since your parent process may not be
  26.    the "master" command shell (see below for an illustration).
  27.  
  28.    It's a can of worms that the makers of most operating systems (OS's),
  29.    including DOS, Unix, OS/2, Win95, et al, have wisely chosen to leave
  30.    sealed!
  31.  
  32.  
  33.  
  34. Q. What good is putenv() if its changes are lost when the program ends?
  35.  
  36.  
  37. A. Its primary use is to set up environment variables prior to spawning
  38.    another subordinate process (program). In the PC world, you'd use it prior
  39.    to issuing a spawn call. In the Unix world, use it prior to using fork()
  40.    and exec().
  41.  
  42.  
  43.  
  44. Q. I know I've seen DOS programs which do modify the master environment, so I
  45.    know it can be done!
  46.  
  47.  
  48. A. Yes it can, but not legally or with guaranteed results. Most OS's do have
  49.    undocumented ways of doing it. DOS is probably the safest to try since
  50.    it's not multiuser or multitasking, and so the only person you can screw
  51.    up is yourself! There are 4 ways to modify a non-local environment under
  52.    DOS. Only one is marginally legal and the others rely on undocumented DOS
  53.    features.
  54.  
  55.  
  56.  
  57. Q. Why was only the DOS batch file and "Stuff-key-buffer method"
  58.    (SETENVAR.C) included in the original SNIPPETS?
  59.  
  60.  
  61. A. The reason that I only included the "batch&stuff" method in my SNIPPETS
  62.    collection is simply that it's the *only* method you can rely on if your
  63.    program is going to be distributed. Quite simply, there is *NO* safe,
  64.    documented way under DOS to set an environment variable in the master
  65.    environment block - period! By back-tracking PSPs or MCBs, you can try
  66.    to locate the master environment and change it. You can also try to use
  67.    Int 2Eh, the command processor's "back door". But all of these methods
  68.    suffer from several shortcomings:
  69.  
  70. 1)  Someone using the program might be using 4DOS, COMMAND PLUS, or some other
  71.     COMMAND.COM replacement. These don't always do things the same way as
  72.     COMMAND.COM and the differences can cause you to crash, roll, & burn! For
  73.     example, several COMMAND.COM replacements allow the master environment
  74.     block to be located in extended, expanded, or high memory. In such a case,
  75.     backtracking PSPs or MCBs is less than useless, they're guaranteed to
  76.     yield undefined errors.
  77.  
  78. 2)  Int 2Eh seems to be the most universally supported, but cannot be used in
  79.     a program invoked from a batch file. The book, "Undocumented DOS" details
  80.     some procedures for making an Int 2Eh call safer but, again, these
  81.     techniques rely on implementation features of COMMAND.COM which might not
  82.     be available in alternate command processors.
  83.  
  84. 3)  Even if everything else is safe, you still need a way of error trapping in
  85.     case your new environment variable might overwrite the end of the
  86.     available master environment block. This error trapping in inherent in
  87.     COMMAND.COM and alternate command processors (one reason why using the
  88.     Int 2Eh back door is potentially the safest way to try), but if you try to
  89.     modify things manually, you're on your own. If you do overwrite the end of
  90.     the master environment block, you'll have automatically corrupted your MCB
  91.     chain and possibly set yourself up for some *really* nasty surprises!
  92.  
  93. 4)  Finally, there's the very fundamental question of which environment block
  94.     really is the master? Say you're in your comm program and hit the "shell
  95.     to DOS" key. A secondary copy of the command processor, be it COMMAND.COM
  96.     or whatever, is spawned and you're off and running. If you now run your
  97.     program from this secondary DOS shell, is its environment block the master
  98.     or is it the one from which you ran your comm program? Worse yet,
  99.     depending on how you set up CONFIG.SYS, the secondary shell may have a
  100.     considerably smaller environment block than the original. Despite having
  101.     set the "/E:" switch, your secondary shell will likely only have an
  102.     environment block whose size is equal to the current block size rounded
  103.     up to the next paragraph boundary. If you trace PSPs, you'll find the
  104.     secondary shell which you stand a good chance of over-running due to the
  105.     difference in the block size. If you trace MCBs, you'll find the real
  106.     master block, but then your changes will have disappeared when you return
  107.     to your comm program, defeating the purpose of your program in the first
  108.     place. 
  109.  
  110.    The inability to alter a parent program's environment block isn't a DOS
  111.    exclusive, BTW - it's an inheritance from Unix where the same limitation
  112.    applies.
  113.  
  114.    Finally, SNIPPETS now includes several of these alternate unsafe ways of
  115.    setting the master environment. INT2E.ASM & CCOMCALL.C together provide
  116.    access to the DOS command processor back door, GLBL_ENV.C provides means
  117.    for TC/TC++/BC++ and MSC/QC programmers to modify the master environment
  118.    by backtracking PSP pointers, and MCB_ENV.C serves the same purpose only
  119.    using the MCB tracking method.
  120.